home *** CD-ROM | disk | FTP | other *** search
/ TPUG - Toronto PET Users Group / TPUG Users Group CD / TPUG Users Group CD.iso / AMIGA / AMICUS / AMICUS01.ADF / Text / Wack Commands < prev    next >
Text File  |  1985-12-04  |  7KB  |  124 lines
  1. From uwvax!seismo!lll-crg!ucdavis!ucbvax!decvax!decwrl!pyramid!amiga!bobp Sun Oct 27 18:50:49 1985
  2. Path: puff!uwvax!seismo!lll-crg!ucdavis!ucbvax!decvax!decwrl
  3.         !pyramid!amiga!bobp
  4. From: bobp@amiga.UUCP (Robert S. Pariseau)
  5. Date: 28 Oct 85 00:50:49 GMT
  6. Reply-To: bobp@snake.UUCP (Robert S. Pariseau)
  7. Organization: Commodore-Amiga Inc., 983 University Ave #D, Los Gatos CA 95030
  8.  
  9.  
  10. This is a copy of a message I posted on BIX a little while back.
  11. -----------
  12.  
  13. It's been said that the Amiga is a hacker's machine.  I surely wouldn't 
  14. dispute that -- that's why we're going public with all (and I mean ALL) of 
  15. the technical info so early.  Hacking, of course, starts with total control.  
  16. In aid of that I'd like to pass on a few hints on how to bend your Amiga to 
  17. your will.
  18.  
  19. 1) Getting into the CLI:  That window you see with copyright message in it 
  20. when you boot the machine is, in fact, a CLI window.  What makes it go away 
  21. is the last line of the startup script (the file Startup-Sequence in the 
  22. directory "s"), to wit "endcli > nil:", which executes an endcli command and 
  23. redirects its good-bye message to the bit-bucket device. Knock that line out 
  24. of the script and you'll always have an instant CLI window when you start -- 
  25. the initial Workbench screen will be underneath it.  
  26.  
  27. But for those of you who only want an instant CLI window SOME of the time, 
  28. there's an easier way.  Wait until the script has started doing the LoadWB 
  29. command (which fires up the Workbench control program out of the firmware) 
  30. and type a CTRL-D!  The CTRL-D tells the CLI script processor to give up 
  31. before starting the next command -- it will NOT interfere with the LoadWB.  
  32. If you still have the standard startup script just type your CTRL-D right 
  33. after the message about using Preferences to set the date and time is printed 
  34. out.
  35.  
  36. 2) Introducing WACK:  The native Amiga debugger is called WACK (acronyms 
  37. invited!).  WACK is a multitasking debugger that runs in a window and allows 
  38. you to debug other programs in the machine.  Those of you with developer's 
  39. kits have a preliminary version of WACK already in hand along with some 
  40. equally preliminary documentation.  Real WACK should be available in stores 
  41. in November.
  42.  
  43. 3) Introducing ROM WACK:  Whether or not you have WACK, every Amiga comes 
  44. with ROM WACK, a subset of WACK stashed in the Kickstart software (Note:  
  45. We've developed the bad habit around here of using the term ROM when we 
  46. really mean Kickstart software kept in the Writeable Control Store -- ROM is 
  47. shorter).  ROM WACK talks out the serial port at 9600 baud.
  48.  
  49. 4) Exec Debug():  The Exec library includes a Debug() entry point that you 
  50. can call in your program when you want to transfer control to the system 
  51. debugger -- kind of a compiled-in breakpoint.  Like every other library entry 
  52. point in the system, Debug() is accessed through an address kept in a table 
  53. in RAM.  That means we can change system debuggers at will!  By default, you 
  54. get ROM WACK.  While WACK itself is running, it installs its entry address in 
  55. the Debug() vector.
  56.  
  57. 5) ROMWack:  Those of you with developer's kits have a program called 
  58. ROMWack.  This program just calls Debug().  Run ROMWack when you want to dump 
  59. yourself into the debugger.  If you don't already have one, create your own 
  60. ROMWack -- it's useful!  By the way, this approach to debugging only works 
  61. due to the multitasking nature of the machine -- keep a CLI free and you'll 
  62. always be able to run the ROMWack program even if whatever you are debugging 
  63. becomes uncooperative.
  64.  
  65. 6) Magic LoadWB switch:  If you are debugging programs under the workbench, 
  66. get into your startup script and replace the LoadWB command with the line 
  67. "LoadWB -debug".  This will cause a magic new menu strip to appear in the 
  68. workbench menus just to the right of "Special".  It doesn't have a title, but 
  69. it's there!  The first item in that menu will cause workbench to call Debug().
  70.  
  71. 7) Exiting ROM WACK:  To return control to your program just after the call 
  72. to Debug(), merely type a CTRL-D to ROM WACK.  Remember that you must do this 
  73. at 9600 baud on the serial port -- use an ASCII terminal or your favorite 
  74. terminal program on another machine (Amiga terminal programs will be 
  75. discussed some other time).
  76.  
  77. 8) WACK commands:  Type "?" to get a list of what WACK or ROM WACK 
  78. understands.  Command names can be abbreviated.  Don't expect too much of ROM 
  79. WACK, it's really a very minimal monitor.  I won't go into more detail on 
  80. commands here -- that would turn this into a manual and, after all, we're 
  81. talking HACKING here!
  82.  
  83. 9) Program traps:  Software failures come in two kinds -- your code and ours. 
  84.  Frankly many of the failures we report as ours are really do to yours 
  85. trampling over our data tables.  In any event, we report ours through Alerts. 
  86.  Alerts are those red on black messages with the flashing red border that 
  87. appear at the top of your screen.  If you haven't seen one yet you've got a 
  88. treat coming -- we've had near heart attacks reported at their appearance.  
  89.  
  90. The "guru meditation" numbers reported in the alert may give you some clue as 
  91. to what's screwed up.  Developers should look in the include file Alerts.i 
  92. (or Alerts.h if you only read C).  For debugging purposes, the key thing to 
  93. remember about Alerts is that the nastiest kind, so called "Dead-end" alerts, 
  94. are actually displayed AFTER the machine is reset.  This is done to GUARANTEE 
  95. that the machine is together enough to display the alert regardless of what's 
  96. gotten screwed up by the failure.  Needless to say, this means that the 
  97. machine state is not very useful for debugging.  
  98.  
  99. But never fear! The system tells you it is about to reset itself by blinking 
  100. the power light (at about half the speed it blinks during the reset time 
  101. diagnostics). If while this light is blinking you type a DEL character on the 
  102. SERIAL port (again at 9600 baud), you will find yourself dumped into ROM WACK 
  103. with the pre-alert state preserved!
  104.  
  105. Most well behaved program failures in YOUR code will present themselves as a 
  106. 68000 exception (e.g., illegal instruction).  If you or your WACK have not 
  107. taken other action, AmigaDOS will catch the trap and display a system 
  108. requester telling you that your task is "held".  
  109.  
  110. This is done because requesters block only one task, whereas alerts disable 
  111. tasking altogether -- very nasty if you are currently writing to the disk in 
  112. some other task!  Wait for the disk lights to go out and then you may safely 
  113. select the Cancel gadget.  When you do that an alert will appear.  The first 
  114. part of the guru numbers is your 68000 exception code (e.g., 3=illegal 
  115. address).  
  116.  
  117. The alert will tell you to click on the left mouse button to continue.  If 
  118. you do that, the machine will reset -- very dull.  What the alert doesn't 
  119. tell you is that, in this very special case of program traps, if you click on 
  120. the right button you will be dumped into ROM WACK (on the serial...you get 
  121. the idea) WITH THE STATE AT THE TIME OF THE EXCEPTION PRESERVED!
  122.  
  123.  
  124.